Brand new to IPF! Just found it last week and my simple rdr seemed to work - until today. Scoured the FAQ, Archive, google and this great writeup: http://www.obfuscation.org/ipf/ipf-howto.txt
I have a very simple one-liner ipnat.conf, on Solaris 10 using the ipf provided by the OS. I just want to redirect port 80 to 8443 to get around running jboss to start on a priv port. r...@dev # cat /etc/ipf/ipnat.conf #!/sbin/ipnat -f - rdr e1000g0 0.0.0.0/0 port 443 -> 0.0.0.0 port 8443 r...@dev # ipf -V ipf: IP Filter: v4.1.9 (592) Kernel: IP Filter: v4.1.9 Running: yes Log Flags: 0 = none set Default: pass all, Logging: available Active list: 1 Feature mask: 0x107 r...@dev # uname -a SunOS dev 5.10 Generic_127112-02 i86pc i386 i86pc It works, but under a very slight load, my Ext/javascript/Ajax client times out on transactions - in fact, I can simulate the timeout by sending our XML commands to a little servlet I wrote. Its not really load - its just how long it takes for the server to respond - I think ipf is closing the socket. If the transaction (Ajax POST to a servlet) on the jboss server (really, tomcat) takes more than ~4 seconds, the browser/client just hangs - the server reports all is well, has sent all the data to the client, no exceptions, no "broken pipes" or anything network related. Any command sent that takes less than this time works fine! Plus, the SAME XML sent to 8443 works fine, using nat, they timeout or abort or simply disappear. Again, all commands "work" to 8443 - if I substitute 443 in my url from the browser, which goes thru the nat/rdr in ipf, "long" transactions disappear or timeout. While I'm running my commands I run this simple loop in another putty while true; do date; ipnat -l ; sleep 1; done (the ipfstat command doesn't have stats on redirections, it appears) and the sessions almost immediately disappear after they're serviced - I get a few during a transaction from my client going to port 443 and in the next loop (after a 1 second sleep), they're gone. Very quick. Too quick? I'm steeped in tcp/udp and all the ndd(1M) timers - expected to see similar to CLOSE_WAIT states, etc. but can't seem to find anything in ipf -T that smells too low. The only tunable I see that resembles something like a timeout on tcp is fr_tcptimeout and it is set to 240, which appears to be 4 * MSL (downloaded source) which is set to 60 - and I get mixed messages via google whether this is ticks (2/sec) or seconds - if seconds, my 4 SECOND connection is certainly under the 4 minute timer if 240 = seconds. I looked in the source for fr_tcptimeout and note from a header file that it appears to read-write - i.e., ipf doesn't have to down for it to change: # define CTLFLAG_OFF 0x00800000 /* IPFilter must be disabled */ # define CTLFLAG_RWO (CTLFLAG_RW|CTLFLAG_OFF) SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcptimeout, CTLFLAG_RWO, &fr_tcptimeout, 0, ""); Can someone help? I've also tried to simply change the setting fr_tcptimeout (assuming I didn't know the units and it was something horrible like ms): I tried Using ipf(1M) r...@dev # ipf -D r...@dev # ipf -T fr_tcptimeout=3600 r...@dev # ipf -T fr_tcptimeout fr_tcptimeout min 0x1 max 0x7fffffff current 3600 r...@dev # ipf -E r...@dev # ipf -T fr_tcptimeout fr_tcptimeout min 0x1 max 0x7fffffff current 240 # reverts back! Using SMF: r...@dev # ipf -T fr_tcptimeout fr_tcptimeout min 0x1 max 0x7fffffff current 240 r...@dev # svcadm disable ipfilter r...@dev # ipf -T fr_tcptimeout=3600 r...@dev # svcadm enable ipfilter r...@dev # ipf -T fr_tcptimeout fr_tcptimeout min 0x1 max 0x7fffffff current 240 Using ipf or SMF I can tell the ipf service is down, as my aforementioned loop starts spewing ioctl problems. Using ADB: r...@dev # echo "fr_tcptimeout/W 3600" | adb -w -k /dev/ksyms /dev/mem physmem 1ff78c adb: failed to dereference symbol: unknown symbol name This makes we worried I don't have the version embedded in the kernel. Next is to try system(4) - but I don't even believe I'm getting a timeout from ipf! Folks were on the box so couldn't reboot then. Thanks for any help! Brian